Я предпочитаю начинать решение проблем в программах с вопроса «а где я ошибся?», так как мой опыт показывает, что в большинстве случаев ошибка именно моя. Но иногда…

Случилось мне заниматься разработкой программного комплекса, один из компонентов которого вертелся в MySQL. При этом всю логику взаимодействия с БД я по возможности перенёс в хранимые процедуры внутри БД. Возникла необходимость оптимизации одной из хранимых процедур, которая при попытке всунуть в БД жалкие 10К строк зависала на два часа. Нужно было найти узкое место этой процедуры. Поиск «бутылочного горлышка» довольно прост: засекаем, сколько миллисекунд уходит на каждый шаг, смотрим, где проблема…

Проблема нашлась гораздо раньше: СУБД категорически отказалась выдавать нам информацию о миллисекундах. Даже под пытками. И даже с Гуглом. При этом информации в интернете было на удивление мало; у меня даже закралось страшное подозрение, которое со временем окрепло, что народ свои базы вообще не оптимизирует. В конце концов Гугл раскололся и выдал ссылку на точное описание проблемы… в багрепорте разработчиков. Читая добросовестное описание проблемы, я испытывал невероятное умиление: моя ситуация один в один! Сейчас дочитаю до ответа разрабов, пойму, где я дурак, всё сделаю как надо… Ответ разрабов был как ушат холодной воды: «Да. Такая проблема существует. MySQL не умеет возвращать миллисекунды».

Не было информации о том, что ведутся работы по устранению проблемы. Ни слово о том, что в версиях с xx.x.xx проблема решена. Просто признание, что жопа есть.

Произнеся приличествующие случаю слова скорби и смирения, я стал думать, как быть в данной ситуации.

На помощь мне пришёл метод Монте-Карло. В моём случае вероятность изменения значения секунды во время атомарной операции была пропорциональна количеству миллисекунд, на эту операцию затрачиваемых. Тут-то и пригодился ввод из 10К строк.

Не могу сказать, что найденное решение уникально. Но в процессе этой разработки я приобрёл полезный опыт, являющийся синтезом двух крылатых фраз: «жизнь — сука, никому нельзя верить» и «на хитрую задницу найдется хвост с винтом».

Кстати, в результате оптимизации я довольно много узнал о внутренней логике MySQL, встроенных в него инструментах отладки и оптимизации и всерьёз зауважал его разработчиков. Временные таблицы, индексы, JOIN вместо вложенных SELECT — и время внесения 10K строк сократилось с двух часов до трёх минут.